In a computing device, a “platform” may comprise equipment and/or software on which an operating system (OS) may execute. For example, when the device is initialized (e.g., booted, rebooted, etc.) firmware may load in the platform to provide software drivers, utilities, interfaces, etc. that the OS may employ to interact with the equipment in the platform. The firmware loaded during device initialization traditionally provided for baseline operation of the device. However, as the technology in computing devices evolves, so does the functionality provided by firmware. Modern firmware not only loads drivers, utilities, etc. that may be essential for device operation and OS/hardware interactivity, but may also provide enhanced functionality such as protective measures. For example, firmware may be configured to load known good programs that verify subsequently loaded programs, and to then encrypt these known-good programs in a secure area within the memory of the device, and thereby ensure that no malicious software (e.g., malware) can compromise the computing device when most vulnerable (e.g., during initialization when no OS-level security software has been loaded). Moreover, firmware may further be able to monitor for equipment changes in the computing device (e.g., peripheral additions and subtractions) and to determine of the equipment changes are safe (e.g., whether added devices are white-listed).
While the benefits of the above functionality are readily apparent, the manner in which to implement this type functionality is not. Firmware based on the Universal Extensible Firmware Interface (UEFI) may provide “runtime” features (e.g., programs that operate in the background while the computing device is operational) that may efficiently implement functionality such as described above, and thus, does not negatively affect the performance of the computing device. This may be compared to a byte code, such as based on the advanced configuration and power interface (ACPI) standard, which may be functional but introduces more processing overhead due to the need for a software interpreter to execute the code. In performing the operations the firmware may need to inform the OS of various events such as, for example, potential security breaches, hardware changes in the device, etc. However, firmware based on UEFI, while more efficient, does not comprise an effective vehicle for generating notifications to an OS in a device.
Although the following Detailed Description will proceed with reference being made to illustrative embodiments, many alternatives, modifications and variations thereof will be apparent to those skilled in the art.